Description (*)

This PR fixes performance issue with huge catalog that have attributes that can have thousands of different options (in our case we have 23000 option for one and 3000-4000 for some others)
The original code for each product, iterates over all possible options to find corresponding label for a product's possible options values (so if a product has 10 option values out of 23000 options, the original code does 22990 extra loops and there is also use of in_array in each of them)
The fix aims to build the attribute option array by the option values as key, so it can only iterate the product's option values (10 items) and use isset instead of in_array

Fixed Issues (if relevant)

1. Elastic Search 5 Indexing Performance Issue #20966: Elastic Search 5 Indexing Performance Issue

Manual testing scenarios (*)

1. test with a huge catalog with million of products and attributes with more than 10000 options
2. reindex catalogsearch_fulltext
3. the products should be indexes in elastic search and be filterablbe

Questions or comments

On a catalog with 1.2 Million product , an attribute with 23000 options and a couple with 3000-4000 and 4 websites the catalogsearch_fulltext took 12hours before the fix and 45min on local devbox after the fix.

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• All automated tests passed successfully (all builds are green)